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with  Air  Force  Instruction  51-303,  it  is  not  copyrighted,  but  is  the  property  of  the  United  States 
government. 
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Introduction 


At  $9-10B  per  year,1  Air  Force  unclassified  space  funding  represents  roughly  eight 
percent  of  the  Air  Force  budget.  Recent  Secretary  of  Defense  (SECDEF)  messages  leave  no 
question  the  entire  Department  of  Defense  (DoD)  enterprise,  including  space,  will  be  scrutinized 
for  warfighter  relevancy3  and  cost-efficiency.4  Air  Force  investments  in  next-generation  space 
systems  will  provide  significantly  enhanced  warfighter  capabilities  over  the  next  two  decades 
that  must  respond  to  SECDEF  Gates’  dual  challenges. 

Today’s  military,  economic,  and  political  influences  constrain  programmatic  action.  The 
SECDEF’s  position  reflects  America’s  economic  situation  that  is  driving  the  need  to  rein  in 
acquisition  costs.5  The  warfighter,  however,  is  engaged  in  military  operations  worldwide  and 
wants  the  acquisition  system  to  respond  more  rapidly  to  evolving  needs.6  At  the  same  time,  the 
Air  Force  is  trying  to  re-establish  credibility  with  Congress  and  is  focused  on  stabilizing 

7 

programs,  not  necessarily  accelerating  programs,  to  ensure  delivery  on  time  and  on  budget. 

Most  importantly,  President  Obama  envisions  space  as  a  key  economic  sector  where  America’s 
best  and  brightest  reign.  President  Obama’s  charge  to  the  space  community  is  expansive: 
“Reduce  programmatic  risk  through  improved  management  of  requirements  and  by  taking 
advantage  of  cost-effective  opportunities  to  test  high-risk  components,  payloads,  and 
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technologies  in  space  or  relevant  environments.”  The  need  for  continued  US  leadership  in 
space  affects  not  only  military  capability  but  the  US  economy  and  diplomatic  relations  as  well. 

This  paper  analyzes  a  critical  segment  of  the  Air  Force’s  space  capability,  particularly  the 
ability  to  link  the  ultimate  user  of  space  information  with  the  warfighter’s  ability  to  extract  and 
leverage  that  information  for  military  operations.  This  paper  considers  economic,  political,  and 
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military  pressures  on  fielding  space  capability  for  the  warfighter  and  proposes  small  changes, 
coupled  with  a  small  investment,  to  manage  change  in  today’s  warfighting  and  acquisition 
environments.  The  recommendations  in  this  paper  align  with  Gen  Kehler’s  vision,  as 
Commander  of  USSTRATCOM,  for  the  military  space  community  to  “exploit  electrons  instead 
of  spending  money.”9 

In  the  following  paragraphs,  two  historical  cases  are  reviewed,  current  requirements  and 
enabling  concept  development  processes  described,  an  analysis  of  the  links  between  these 
processes  presented,  and  a  summary  of  the  effectiveness  of  these  processes  is  presented.  Several 
recommendations  for  improving  the  link  between  system  developers  and  warfighters  are 
proposed  to  be  consistent  with  senior  leader  visions  for  space  operations  and  acquisition. 

The  value  of  space-based  information  to  the  US  military  is  well  understood.10  Space 
systems  underpin  successful  global  operations  by  providing  communication,  navigation,  weather, 
reconnaissance,  and  other  data.  The  first  Gulf  War,  dubbed  the  first  “space  war”  by  Generals 
McPeak  and  Fogelman,  was  clearly  a  success  in  adapting  strategic  space  assets  to  the  tactical 
fight.11  The  Air  Force  learned  valuable  lessons  from  that  experience  including  the  importance  of 
space  to  the  warfighter. 

For  example,  during  the  first  Gulf  War,  satellite  operators  and  engineers  adjusted  Defense 
Support  Program  (DSP)  satellite  support  to  meet  warfighter  needs.  DSP  was  originally  built  to 
detect  strategic  Soviet  intercontinental  and  submarine  ballistic  missile  launches  in  sufficient  time 
for  US  missile  crews  to  be  alerted  and  launch  a  retaliatory  attack,  thereby  assuring  destruction  of 
the  Soviet  Union  should  it  initiate  a  nuclear  attack  on  America.  During  the  first  Gulf  War, 
however,  DSP  performance  requirements  were  updated  to  detect  Saddam  Hussein’s  smaller 
tactical  scud  missiles.  Hussein  used  scuds  to  harass  coalition  troops  and  antagonize  Israel  in  an 
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effort  to  break  up  the  coalition  against  Iraq.  To  counter  the  scud  threat,  warfighters  identified 
theater  information  needs  for  missile  warning  to  provide  adequate  time  to  defend  against  attack 
and  take  cover.12  From  theater  requirements,  the  DSP  team  “tweaked  the  system”13’14  so  Patriot 
missile  units  received  early  warning  of  incoming  Scud  missiles,  enabling  sufficient  time  to 
launch  defensive  missiles  and  alert  personnel  to  take  cover.  The  space  community’s  innovative, 
responsive  approach  to  warfighter  feedback  contributed  to  a  strategic  win  for  Coalition  forces.15 

As  a  direct  outcome  of  lessons  from  the  Gulf  War,  the  Air  Force  created  the  1 1th  Space 
Warning  Squadron  and  outfitted  the  unit  with  a  prototype  system  to  experiment  with  new 
concepts  for  using  DSP  data.  The  lessons  learned  from  this  prototyping  effort  fed  the  follow-on 
development  program,  Space  Based  Infrared  System  (SBIRS),16  with  new  warfighter 
requirements  for  improving  missile  warning  from  space-based  platforms.  This  pattern  of 
developing  prototype  systems,  enabling  warfighter  experimentation,  obtaining  feedback  from 
simulations,  then  developing  requirements  to  update  the  baseline  system  is  an  example  of  a  tight, 
controlled  feedback  loop  between  warfighter  and  developer. 

Another  example  of  successful  prototyping  is  the  Talon  NAMATH  system,  developed 
through  the  Air  Force  Tactical  Exploitation  of  National  Capabilities  (AFTENCAP),  to  provide 
extremely  high  accuracy  Global  Positioning  System  (GPS)  data  to  the  theater.  Talon  NAMATH 
receives  near-real-time  GPS  data,  reformats  the  data  to  be  compatible  with  joint  forces,  then 
pushes  the  final  product  to  theater  for  operations  requiring  more  accuracy  than  the  signal-in¬ 
space  currently  provides.17  Identified  as  a  “good  prototyping  approach”18  by  (then)  GPS  Wing 
Commander  Col  Dave  Madden,  Talon  NAMATH  was  developed  and  fielded  in  just  over  one 
year  for  only  three  million  dollars.19  Because  of  Talon  NAMATH,  warfighters  executed 
bombing  missions  with  minimum  collateral  damage  and  America  reduced  negative  publicity 
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resulting  from  civilian  casualties.  The  prototype  data  continues  to  be  available  for  theater 
operations  today. 

Both  DSP  and  GPS  prototypes  successfully  adapted  space  system  products  to  meet 
warfighter  tactical  needs,  thus  demonstrating  the  relevancy  of  space  information  to  warfighters. 
However,  both  examples  reflect  unique  approaches  rather  than  a  routine  prototyping  method. 
Efficiency  favors  repeatability;  devising  an  efficient  approach  requires  understanding  current 
processes  and  the  key  links  into  those  processes. 

Current  Processes 


When  warfighters  need  new  materiel,  high  level  documents  are  produced  to  describe  the 
capability  gap  that  exists  and  identify  desired  system  performance  to  fill  the  gap  (e.g.,  system 
availability,  accuracy,  event  reporting  timelines).  These  capability  requirements  documents  are 
approved  by  the  Vice  Chairman  of  the  Joint  Chiefs  of  Staff  at  the  Joint  Requirements  Oversight 
Council  (JROC).  An  updated  JROC-approved  document  accompanies  each  acquisition 
milestone  decision  (Figure  1)  to  ensure  warfighter  requirements  remain  aligned  with  materiel  as 
development  progresses.  Capability  document  development  and  staffing  is  nominally  one  to  two 
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years,  depending  on  the  maturity  of  the  document.” 


Figure  1  -  Capability  Documents  and  Acquisition  Milestones  Relationship 
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The  Enabling  Concept  (EC)  is  typically  developed  by  the  same  team  responsible  for  the 
JROC  requirements  documents.  The  EC  documents  how  the  system  will  be  used  in  operations, 

thus  providing  context  for  warfighter  requirements.  An  EC  is  expected  to  require  several 
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iterations  and  a  lengthy  staffing  process  unless  changes  are  only  administrative  in  nature. 

The  two  processes,  requirements  and  EC  development,  produce  foundational  documents 
that  define  the  characteristics  required  of  a  system  and  expected  operational  use  of  that  system. 
These  processes  are  largely  linked  through  governing  regulations,  systems  engineering  and  key 
personnel.  Each  link  will  be  separately  analyzed  in  the  following  paragraphs. 

Process  Link  -  Governing  Regulations 

Air  Force  space  ECs  are  developed  in  accordance  with  Air  Force  Space  Command 
Instruction  (AFSPCI)  10-102  to:  “ explain  an  idea  of  how  to  produce  warfighting  effects  [and]  lead 
the  requirements  and  acquisition  processes  by  articulating — in  operational  terms — the  necessary 
and  supporting  capabilities  to  produce  these  effects  [emphasis  in  original].”23  Air  Force  Space 
Command  (AFSPC)  envisions  ECs  will  evolve  in  parallel  with  system  development  until  sufficient 
design  maturity  allows  an  initial  operating  concept  to  be  developed.  The  initial  operating  concept 
will  be  used  to  develop  tactical  procedures,  generate  operational  test  scenarios,  and  define  operator 
tasks. 

Conversely,  acquisition  leaders  emphasize  the  need  to  stabilize  requirements  and  eliminate 
sources  of  requirements  creep.24  The  space  acquisition  community,  in  particular,  is  concerned  with 
the  enormous  up-front  investment  required  to  develop,  build,  and  launch  satellites.25  As  a  result, 
space  acquisition  rules  are  geared  toward  ensuring  early  requirements  stability,  calling  for  an  initial, 
partially  complete  EC  at  Milestone  A  followed  by  a  final  EC  at  Milestone  B.26  While  the  policy 
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allows  for  an  EC  update  at  Milestone  C,  the  expectation  is  no  design-driving  requirements  will  be 
introduced.27 

Acquisition  regulations  clearly  expect  requirements  lockdown  at  Milestone  B  while  AFSPCIs 
encourage  EC  evolution  until  the  system  is  fielded.  AFSPCIs  don’t  identify  the  need  to  constrain  EC 
updates  within  Milestone  B  requirements.  Likewise,  space  acquisition  regulations  assume  EC 
analysis  conducted  between  Milestone  B  and  Milestone  C  won’t  reveal  unacceptable  operational 
situations  or  identify  new  information  needs  that  force  requirements  changes.  Warfighters  assume 
their  needs  will  be  reflected  in  the  design  as  the  operational  environment  is  clarified,  while  program 
managers  assume  no  changes  will  be  made  so  cost  and  schedule  commitments  can  be  met. 

Programs  can  take  several  years  to  mature  from  Milestone  B  to  Milestone  C.  During  that 
time,  these  disconnected  regulations  encourage  warfighters  and  acquisition  teammates  to  manage 
requirements  differently.  This  divergent  management  approach  can  result  in  unmet  expectations, 
leading  to  organizational  friction  and  wasted  time  if  system  features  are  incompatible  with 
warfighter-envisioned  operations. 

While  warfighter  appetite  for  change  must  be  realistically  bounded,  legitimate  requirements 
changes  can  also  arise.  Program  Managers  have  a  legitimate  need  to  minimize  requirements  creep. 
This  source  of  conflict  must  be  acknowledged  and  managed  to  ensure  relevant  space-based 
information  capability  is  fielded.  With  the  right  tools,  the  systems  engineering  process  can  be  the 
mechanism  for  managing  this  conflict. 

Process  Link  -  Systems  Engineering 

The  systems  engineering  process  (Figure  2)  is  used  to  refine  capability  requirements  from 
JROC-approved  documents  into  lower  level  design  requirements  (e.g.,  crew  size,  skill  levels,  and 
basing  locations).  External  requirements  (e.g.,  environmental  laws,  information  assurance 
requirements)  are  added  to  the  capability  requirements.  The  capability  and  external  requirements 
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are  linked  together  logically,  then  alternative  design  solutions  are  developed.  Several  iterations 
between  requirements,  logic,  and  design  may  be  required  before  a  complete  set  of  requirements 
is  baselined  for  product  development. 
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Figure  2  -  Systems  Engineering  Process28 


The  acquisition  best  practice  is  to  establish  the  requirements  baseline  early,  then  leave  the 
established  baseline  alone  during  design  to  avoid  costly  requirements  creep.  Typically,  the  only 
new  requirements  added  after  Milestone  B  are  those  needed  to  avoid  mission  failure.  All 
remaining  requirements  changes  are  identified  for  planned  upgrades  after  the  system  is  fielded. 

But  changes  postponed  to  future  upgrades  may  not  be  added  to  the  baseline  for  several 
years.  New  capability  requirements  must  first  be  refined  into  design  requirements  so  the 
contractor  can  estimate  the  effort.  Then,  the  Government  requests,  receives,  and  evaluates  the 
contractor’s  change  proposal  to  ensure  the  work  required  is  the  work  planned.  Finally,  the 
contract  change  is  negotiated  to  ensure  the  Government  receives  a  fair  price.  Once  these  steps 
are  complete,  the  change  is  designed  and  built.  This  process  is  likely  to  take  one  to  two  years, 
depending  on  how  well  the  change  is  understood  by  both  the  Government  and  the  contractor. 

As  a  result  of  this  lengthy  effort,  innovative  warfighters  charted  a  new  course  to  avoid  the 
lengthy  contract  modification  process.  Warfighters  discovered  prototype  systems  can  meet 
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AFSPCI  63-104  criteria,  be  approved  for  operations,  and  fielded  to  meet  warfighter  need  by 
creating  a  separate  system  baseline  for  the  desired  capability. 

While  this  approach  often  works  well  in  meeting  the  warfighter’s  urgent  need,  systems 
that  comply  only  with  AFSPCI  63-104  may  not  fully  meet  critical  program  requirements  (e.g., 
information  assurance)  or  include  plans  for  lifecycle  sustainment  (e.g.,  software  changes). 

Unless  contractually  connected  to  the  program  of  record,  off-line  systems  will  likely  require  a 
separate  sustainment  effort  for  maintenance,  upgrades,  and  spares  to  ensure  the  operational 
reliability  and  availability  rates  expected  by  the  warfighter  are  met.  In  addition,  because  systems 
can  be  fielded  without  meeting  all  system- level  requirements,  off-line  system  data  products  may 
not  carry  the  same  level  of  mission  assurance  as  the  baseline  system  (e.g.,  data  authenticity  or 
integrity). 

For  example,  Talon  NAMATH  was  developed  outside  normal  acquisition  channels. 
Timely  fielding  of  an  effective  warfighting  tool  was  achieved;  but,  because  prototyping  was 
conducted  outside  the  system  baseline,  long  term  sustainment,  integration  into  the  baseline 
system,  and  system-level  requirements  validation  were  minimally  addressed.  This  set  up  Talon 
NAMATH  to  be  a  separate  system,  with  a  separate  support  contract,  for  the  life  of  the  program. 
Although  efficiency  of  this  approach  is  less  than  desirable,  Air  Force  management  can  and  did 
adapt  to  the  Talon  NAMATH  arrangement  because  of  the  enormous  warfighter  benefit  derived 
from  the  system.  But,  if  the  Talon  NAMATH  approach  becomes  the  standard  change  process, 
every  new  data  capability  will  require  separate  support  systems  for  the  life  of  the  program.  With 
numerous  future  capabilities  in  the  development  queue,  this  prototype  process  will  result  in 
unnecessarily  complex  ECs  and  inefficient  sustainment  practices  due  to  multiple  separate 
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Systems  engineering  can  provide  cost-efficient  warfighter-relevant  capabilities.  But, 
without  reducing  the  time  to  execute  baseline  changes,  off-line  solutions  will  continue  to  be 
attractive  for  meeting  warfighter  needs  identified  in  EC  updates. 

Process  Link  -  Decision  Process 

To  write  an  EC,  action  officers  (AOs)  from  Air  Force  Space  Command  organize  and  lead  a 
multi-organization  team  through  a  series  of  writing  conferences.  Per  regulation,  AOs  are  expected  to 
both  finalize  the  EC  at  Milestone  B  (DoD  5000.2)  and  evolve  the  EC  into  an  initial  operational 
concept30  without  introducing  a  new  design  driver  at  Milestone  C  (DoD  5000.2).  In  parallel,  the  AO 
builds  or  updates  the  capability  requirements  document.  Presently,  no  automated  tools  are  used  to 
link  the  EC  with  requirements.31 

AOs  must  close  the  regulation  gaps  while  writing,  rewriting,  staffing,  and  maintaining 
synchronization  of  two  foundational  documents  in  order  to  describe  needed  warfighter  capability. 
This  third  process  link  relies  heavily  on  AO  experience,  drive,  objectivity,  determination,  and 
workload.  As  new  capabilities  are  delivered,  AOs  will  need  updated  tools,  regulations,  and  processes 
in  order  to  keep  pace  with  change. 

Current  Effectiveness 

Today’s  processes  are  effective  because  Air  Force  professionals  work  through  the  issues  as 
they  arise.  However,  with  multiple  new  capabilities  coming  on  line,  the  Air  Force  will  likely  find 
this  inelegant  “system”  cannot  keep  up  with  the  demand  for  new  capability.  On  the  other  hand,  if  the 
Air  Force  relies  on  off-line  development,  more  money  will  be  needed  to  sustain  multiple  baselines  - 
budget  the  Air  Force  is  no  longer  expecting  to  have.  Good  stewardship  of  taxpayer  money  is  only 
one  aspect  of  meeting  our  commitment  as  “Guardians  of  the  High  Frontier.”32  To  maximize 
capability  from  space  system  investments,  AFSPC  key  personnel  need  a  system,  tools,  and  the 
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authority  to  manage  evolving  warfighter  requirements  so  effectiveness  and  efficiency  are  addressed 
in  the  fielded  product. 

Recommendations 

A  controlled  method  is  needed  to  allow  evolving  EC  requirements  to  drive  space-based 
information  capability  design.  Establishing  this  methodical  approach  requires  three  changes.  First, 
regulations  must  be  updated  to  balance  requirements  stability  and  evolving  requirements.  Second, 
systems  engineering  processes  need  to  accommodate  change  while  minimizing  disruption  when 
change  is  required.  Third,  formal  decision  processes,  involving  both  program  managers  and 
warfighters,  are  needed  to  support  change  decisions. 

Regulation  Updates 

To  close  the  expectation  gap  between  warfighters  and  program  managers,  DoD  5000.2  and 
AFSPCIs  need  to  be  aligned.  While  DoD  5000.2  favors  rejecting  design-driving  changes  after 
Milestone  B,  changes  that  do  not  drive  design  are  left  to  the  Program  Manager’s  discretion.  If,  for 
example,  an  enabling  concept  identifies  a  superficial  change  (e.g.,  a  more  efficient  method  for 
presenting  information),  DoD  5000.2  allows  the  program  manager  to  consider  the  change,  assuming 
cost,  schedule,  performance,  and  risk  are  acceptable. 

Because  change  is  not  desired  unless  absolutely  necessary,  both  AFSPCI  10-102  and 
AFSPCI  10-604  need  to  be  updated  to  reflect  the  Milestone  B  constraints  of  DoD  5000.2  and  limit 
EC  changes  to  the  greatest  extent  possible.  However,  change  may  be  unavoidable  and  when  it  is 
deemed  crucial  to  change,  the  systems  engineering  process  must  be  sufficiently  robust  to  consider  the 
change  while  continuing  the  baseline  development. 
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System  Engineering  Updates 


All  programs  are  required  to  establish  a  systems  engineering  process  at  Milestone  B  to 
control  the  product  baseline.  A  good  systems  engineering  process  should  consider  three  aspects 
of  change  in  order  to  minimize  disruption  of  the  design  process:  1)  timing  of  change  in  relation 
to  the  baseline  stability,  2)  impact  of  change  to  the  baseline  design  and  3)  fidelity  of  the  change 
definition. 33 

First,  the  right  time  to  introduce  change  is  highly  dependent  on  baseline  stability.34 
Introducing  requirements  change  during  development  can  result  in  multiple  changes  to  the  same 
design  element,  causing  confusion  and  slowing  system  maturity.  However,  changing  aspects  of 
the  system  that  are  stable  can  result  in  very  little  design  impact.  Disruption  can  be  minimized  if 
the  change  is  introduced  when  the  baseline  is  stable.  Program  managers  are  aware  of  the 
stability  of  the  baseline  through  active  participation  in  the  contractor’s  configuration 
management  boards.  No  change  is  needed  to  the  existing  systems  engineering  process  provided 
programs  are  actively  managed. 

Second,  the  impact  of  the  change  drives  the  amount  of  resources  needed  to  execute  the 
change.  For  example,  if  a  significant  portion  of  the  baseline  is  affected  by  a  requirements 
change,  more  designers,  testers,  and  test  assets  will  be  needed  to  work  on  the  baseline  change. 
Since  these  resources  are  also  needed  to  design  the  baseline  program,  the  change  is  likely  to  pull 
resources  from  the  main  development  effort  in  order  to  work  on  the  change.  This  will  result  in 
higher  cost  and  longer  development  schedules.  In  some  cases,  additional  personnel  can  be  hired; 
however,  new  personnel  are  not  always  available  or  properly  trained.  The  amount  of  resources 
needed  to  work  on  a  change  is  critical  information  for  gauging  disruption  created  from  adding 
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requirements.  This  knowledge  comes  from  fully  understanding  the  change  and  the  resource 
constraints  of  the  program. 

Finally,  fidelity  of  change  definition  is  needed  to  properly  scope  cost,  schedule, 
performance,  and  risk  impacts  resulting  from  baseline  changes.  Lower  level  baseline  impacts  are 
difficult  to  pin  down  if  the  developer  is  only  provided  with  a  capabilities-level  requirement 
change.  A  method  is  needed  to  refine  changes  from  EC  updates,  which  tend  to  be  capabilities- 
based,  into  technical  requirements  that  can  be  used  to  determine  baseline  change  impacts. 

The  ability  to  experiment  with  EC  changes  using  an  off-line  system  prototype  would 
provide  a  mechanism  for  systems  engineers  to  evaluate  both  the  impact  and  fidelity  of  a 
proposed  design  change  before  any  baseline  change  is  directed.  Facts  can  be  gathered  and 
requirements  refined  so  cost,  schedule,  performance,  and  risk  estimates  are  available  to  decision 
makers  before  any  change  decision  is  made. 

The  expected  benefit  of  using  a  prototype  to  augment  the  systems  engineering  process 
(Figure  2)  is  reduced  iteration  time  between  each  step  through  early,  complete,  identification  of  a 
change  before  the  baseline  is  disturbed.  For  example,  a  prototype  of  a  proposed  EC  change  can 
provide  an  early  instantiation  of  the  operational  concept,  provide  early  indications  of  the  baseline 
changes  required,  and  be  conducted  off-line  so  primary  development  is  not  interrupted  until  the 
change  is  well  understood.  Because  prototypes  are  not  operational  software,  partial  solutions  can 
be  demonstrated  to  the  warfighter  and  his  feedback  incorporated  before  establishing 
requirements.  In  this  manner,  change  can  be  managed  off-line  until  requirements  are  sufficiently 
refined  to  quickly  develop  technical  proposals  that  minimally  disrupt  established  design 
activities.  Once  approved,  the  requirements  will  be  subject  to  the  full  set  of  requirements 
applicable  to  the  baseline  system  and  be  absorbed  into  the  baseline  sustainment  program. 
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Between  active  program  management  and  introduction  of  prototypes  to  define  change, 
the  systems  engineering  process  can  be  established  to  manage  change  while  minimizing 
disruption  to  the  baseline.  The  key  to  increasing  speed  of  the  systems  engineering  process  is 
ensuring  adequate  information  is  available  to  warfighters  and  developers  so  informed  decisions 
are  made. 

Formal  Decision  Process 

With  facts  from  prototype  activities  available  to  decision  makers,  a  fairly  straight-forward 
decision  process  can  be  defined.  Requirements  changes  ultimately  need  to  be  approved  by  the 
requirements  manager  in  AFSPC/A5.  Similarly,  the  development  baseline  can  only  be  changed 
with  concurrence  from  the  Program  Director.  In  the  proposed  decision  structure  changes,  the 
Program  Director  retains  the  contract  change  management  function,  to  include  timing  of  change, 
so  disruption  to  the  baseline  design  is  minimized.  AFSPC/A5  ensures  any  change  is  truly 
required  by  warfighters.  The  AFSPC  AO  continues  to  be  the  key  to  connecting  the  EC  and 
requirements  processes  facilitating  all  change  decisions. 

The  process  outlined  in  Figure  3  is  one  possible  decision  structure  for  refining 
requirements  resulting  from  EC  updates.  First,  through  the  EC  update  process,  a  new  capability 
need  is  identified  (e.g.,  merge  three  information  displays  into  one).  Next,  the  change  is  modeled 
with  process  tools35  to  visualize  changes  to  operations  decisions,  tasks,  and  information  flows 
(e.g.,  merging  data  may  reduce  task  load  for  one  operator  but  increase  task  load  for  another).  If 
the  change  provides  no  operational  benefit,  no  further  action  is  required.  If  the  change  results  in 
a  positive  effect,  a  prototype  is  developed  to  visualize  the  potential  EC  update.  The  developer 
should  receive  high  level  capability  requirements  and  be  directed  to  deliver  cost,  schedule,  and 


13 


performance  impacts,  along  with  a  risk  assessment  of  turning  the  prototype  into  a  change  to  the 
product  baseline. 

Once  completed,  the  prototyped  EC  change  should  be  reviewed  by  the  EC  team  and  an 
assessment  of  the  benefit  to  operations  provided  to  the  AO.  In  parallel,  the  Program  Manager 
(PM)  should  review  the  developer’s  deliverables  and  generate  an  independent  cost,  schedule, 
performance,  and  risk  assessment  to  the  AO.  The  AO’s  assessment,  based  on  prototype  results 
and  the  PM’s  assessment,  should  form  a  recommendation  to  the  AFSPC/A5  and  Program 
Director  that  AFSPC  accept,  reject,  or  delay  the  proposed  baseline  change. 

Of  note,  steps  1  and  5  (requirement  and  approval)  are  unchanged  from  today’s  approach. 
Similarly,  step  2  (operations  modeling)  is  conducted  today;  however,  it  may  not  be  conducted 
with  automated  tools  that  enable  rapid  assessment  of  the  change  and  its  impact  on  information 
flow.  The  new  aspects  of  change  approval  are  the  additional  information  received  from  the 
prototyping  effort,  the  EC  team’s  ability  to  assess  the  change,  and  the  detailed  programmatic 
information  now  available  to  the  PM  to  assess  the  proposed  update’s  impact  on  the  baseline 
development. 
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Figure  3  -  Decision  Process  for  Baseline  Change 


AFSPC,  with  the  dual  responsibility  to  field  operationally  useful  systems  and  maintain 
acquisition  program  cost  and  schedule,  should  require  any  EC  changes  be  successfully  prototyped 
before  being  considered  for  a  baseline  change.  This  prototyping  should  support  a  cost/benefit 
analysis  so  demonstrated  operational  advantages  are  determined  to  be  commensurate  with  the  cost  of 
the  change.  To  ensure  the  acquisition  remains  on  track,  the  PM  must  determine  if  the  change  can  be 
incorporated  into  the  on-going  design  (e.g.,  limited  to  repackaging  information  available  in  the 
baseline  system  design)  or  delayed  to  the  next  major  upgrade  (e.g.,  redesign  of  a  subsystem).  The 
organizational  structure  required  to  implement  this  guidance  must  ensure  both  the  program  office  and 
headquarters  have  sufficient  visibility  and  authority  to  consider  the  cost,  schedule,  performance,  and 
risks  associated  with  a  proposed  change. 
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Conclusion 


Prototyping  is  not  a  new  concept;  in  fact,  recent  changes  to  acquisition  law  mandate 
competitive  prototyping  prior  to  Milestone  B36  because  Congress  believes  prototyping  reduces 
risk  to  the  government.  This  paper  proposes  prototyping  for  risk  reduction  as  well,  but  focuses 
on  the  post-competitive  phase  of  acquisition  by  addressing  the  risk  associated  with  changing 
requirements  after  establishing  the  design  baseline. 

This  paper  highlights  the  approaching  situation  where  space-based  information 
requirements  will  change  after  the  baseline  is  established  at  Milestone  B.  Gaps  exist  between 
enabling  concept  and  requirements  processes  that  elongate  timelines  between  warfighter  need 
and  fielded  materiel  solutions  because  current  process  rely  on  key  personnel  to  identify  and  fix 
incompatibilities  between  enabling  concepts  and  requirements.  In  addition,  lack  of  a  prototype 
impairs  the  ability  of  warfighters  to  visualize  the  system  they  will  operate  until  the  product  is 
mature. 

Implementing  a  prototype  system  requires  some  investment.  Funding  will  be  required  for 
the  prototype,  contractor  personnel  manning,  a  prototype  lab,  and  prototype  projects.  AFSPC 
will  need  to  designate  a  dedicated  team  of  experienced  operators  to  interact  with  prototypes  and 
determine  if  the  enabling  concept  and  system  design  are  compatible.  Once  fielded,  warfighter 
feedback  will  need  to  be  rolled  in  to  ensure  system  upgrade  efforts  are  properly  scoped. 

An  area  requiring  further  study  is  integration  of  prototypes  from  organizations  outside  the 
program  office.  For  example,  AFSPC’ s  Space  Innovation  &  Development  Center  (SIDC) 
produces  effective  prototypes  routinely.  This  organization  brought  both  Talon  NAMATH  and 
the  11  Space  Warning  Squadron  capabilities  on  line.  If  integrated  into  the  EC  updates  and 
contractually  linked  to  a  program  of  record,  SIDC  prototypes  may  lead  to  an  even  tighter  link 
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between  warfighters  and  materiel  developers  -  ultimately  improving  effectiveness  and 
efficiency. 

For  a  small  investment  (perhaps  ten  percent  of  program  cost)  ,  AFSPC  stands  to  gain 
significant  credibility  by  leveraging  post-award  prototyping  to  ensure  new  capabilities  are 
provided  quickly  to  the  warfighter.  The  risk  associated  with  off-line  prototyping  is  minimal  as 
the  baseline  product  is  untouched  until  accountable  managers  decide  the  risk  of  disrupting  the 
development  with  a  new  requirement  is  minimized.  Prototyping  requirements  changes  after 
Milestone  B  addresses  the  President’s  charge  to  reduce  risk  by  managing  (not  freezing) 
requirements,  provides  an  opportunity  to  more  rapidly  insert  warfighter  capability,  and  can  be 
implemented  to  maximize  sustainment  efficiencies.  With  several  systems  in  the  post-award 
phase  and  delivery  just  around  the  corner,  the  Air  Force  needs  to  prepare  for  success  —  the 
implementation  proposed  in  this  paper  is  entirely  within  AFSPC’s  authority  and  should  be 
considered  as  a  controlled  approach  to  tackling  several  senior  level  concerns. 
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